Most optimizers enforce “hard” constraints with high cost penalties. That makes them pseudo constraints: expensive soft constraints pretending to be hard. In complex scenarios, they break. Pillar Nodes solve this with a fundamentally different approach: the optimizer’s architecture makes SLA violations structurally impossible, not merely expensive.
Hard constraints never compete with soft constraints. They are separate layers. The result: guaranteed feasibility and better optimization at the same time.
A major field-service operator with thousands of technicians, tens of thousands of daily dispatches, and contractual SLAs on every appointment ran into a wall. Their optimizer enforced “hard” constraints through extremely high cost penalties. It worked for simple scenarios. But as real-world complexity grew (overlapping time windows, mandatory certifications, multi-day shifts, cascading dependencies), the results became problematic. SLAs were missed. The optimizer was spending all its effort satisfying pseudo-hard constraints instead of actually optimizing the schedule.
The root cause was not the solver. It was the modeling approach. Penalty-based “hard” constraints are pseudo constraints. They are expensive soft constraints pretending to be hard. In sufficiently complex scenarios, they break. That is not a tuning problem. It is a fundamental limitation.
We built Pillar Nodes to solve this. Not with higher penalties. With a different architecture.
“It is hard to tell an optimizer that being 10 minutes late at one appointment is fine, but for another, it is not acceptable. High penalties cannot solve this. We had to change the architecture itself.”
Dr. Jens Richter, DNA Evolutions GmbHA Pillar has a predefined time window that cannot be violated. Not “should not.” Cannot. The optimizer’s architecture makes it structurally impossible to produce a solution that misses a Pillar’s SLA.
Other nodes in the schedule flow around the Pillar. They shift, reorder, or move to different resources to keep the Pillar’s time window intact. The Pillar can optionally move within its window, or be fully fixed. In all cases, the window boundaries are inviolable.
If no valid schedule exists at all, the Pillar is canceled rather than violated. Contract cancellation over contract violation. Damage control by design.
In the complex, real-world scenarios that inspired this feature, cost-based pseudo-hard constraints consistently produced problematic results. The optimizer traded violations between competing constraints, because a cost function simply cannot distinguish “preferred” from “legally required.” Pillar Nodes eliminate this problem entirely.
JOpt supports hard constraints across multiple dimensions, including mandatory resource assignment and skill/type matching. A Pillar can be coupled to a specific resource, guaranteeing not just when but who. Every hard constraint in JOpt can also be configured as a soft constraint if desired, giving you full control over the boundary between obligation and preference.
In JOpt, a hard constraint is an architectural property, not a cost property. Hard constraints are part of the data model. They define the feasible space. Soft constraints optimize within it. The two layers never compete.
| Pseudo-hard (penalty-based) | JOpt Pillar (architectural) |
|---|---|
| × High cost, can still be violated | ✓ Architecture, cannot be violated |
| × Competes with soft constraints | ✓ Separate layer, no interference |
| × Degrades as complexity grows | ✓ Scales with complexity |
| × No feasibility guarantee | ✓ Every solution structurally valid |
Contractual SLAs. Legal obligations. Dangerous-goods certifications. Named-person commitments. Anything where violation has consequences no cost model can represent.
Preferred time slots. Customer wishes. The cost function handles these perfectly because it is not burdened with pseudo-hard constraints competing for optimizer budget.
Run a Docker sandbox. Open PillarExample.java. Watch other nodes flow around the Pillar.